Self-Hosted Services
A self-hosted
service can be any managed application or application domain. Managed
applications include Windows Forms applications, console applications,
or Windows services. Similar to other hosting environments, the ServiceHost<T>
generic class is used to host WCF endpoints within any .NET
application. If the host is a Windows Forms or console application, it
must be running to provide an application domain to host the
communication endpoints.
Self-hosted services
offer unique advantages, such as using TCP, IPC, or MSMQ for transport,
utilizing HTTP with multiple ports (besides port 80), and programmatic
access to hosting features. With self-hosting, the service is not
limited to HTTP-based addresses as is the case with IIS.
|
A primary service-orientation principle that can greatly impact service hosting considerations is Service Autonomy .
It advocates that services have as much control over their underlying
execution environment as possible in order to guarantee a high level of
behavioral predictability. This generally implies that allocated
resources are desirable, whereas shared resources are not.
|
It is a flexible approach, but
it has the least amount of server features. It is not a valid option if
you need high availability, reliability, and a management view. The
most common scenario for self-hosting is a smart client application
which, when you fire it up, provides a connection point for other
applications. Peer-to-peer applications are a common example of
self-hosted services.
The
following example shows a service that, when implemented in a Windows
Forms application or a Console application, would be classified as
self-hosted. In this case the ServiceHost
class is instantiated by providing the constructor the interface and
base addresses (and the binding is inferred from the address which is
in the configuration file shown in Example 2).
Example 2.
Uri[] baseAddresses = new Uri[]
{
new Uri(ConfigurationManager.AppSettings["tcpBaseAddress"]),
new Uri(ConfigurationManager.AppSettings["httpBaseAddress"])
};
ServiceHost serviceHost =
new ServiceHost(typeof(AccountService), baseAddresses);
serviceHost.Open();
|
The base address collection provided to the ServiceHost instance is dynamically configured by reading the settings from the Web.Config file:
Example 3.
<appSettings>
<add key="tcpBaseAddress"
value="net.tcp://localhost:1234"/>
<add key="httpBaseAddress"
value="http://localhost:8000"/>
</appSettings>
|
The ServiceHost class
uses endpoint information, such as the address, binding, and contract,
to initialize and create a process and its underlying communication
stack in the application domain that receives messages:
Example 4.
<services>
<service name ="AccountService">
<endpoint name="EndPoint1"
address=""
binding="netTcpBinding"
contract="IAccount"/>
<endpoint name="EndPoint2"
address=""
binding="basicHttpBinding"
contract="IAccount"/>
</service>
</services>
|
.NET
4.0 simplifies WCF configuration by providing a default configuration
and behavior. The default configuration also includes a default
endpoint. Therefore, it is possible to consume a WCF service with no
supporting configuration file. The binding defaults to basic HTTP (BasicHttpBinding),
but if a different binding is required, it needs to be changed in the
App.Config file. This allows you to rapidly create a Web service
similar to .ASMX development.
Note that this
technique is not generally recommended when applying
service-orientation as it tends to promote RPC-style inter-service
relationships.
